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Indication of Message Composition for Instant Messaging 


Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 


Copyright (C) The Internet Society (2005). 


Abstract 


In instant messaging (IM) systems, it is useful to know during an IM 
conversation whether the other party is composing a message; e.g., 
typing or recording an audio message. This document defines a new 
status message content type and XML namespace that conveys 
information about a message being composed. The status message can 
indicate the composition of a message of any type, including text, 


voice, or video. The status messages are delivered to the instant 
messaging recipient in the same manner as the instant messages 
themselves. 
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1. Introduction 


By definition, instant messaging (IM) is message based: A user 
composes a message by, for example, typing, speaking, or recording a 
video clip. This message is then sent to one or more recipients. 
Unlike email, instant messaging is often conversational, so the other 
party is waiting for a response. If no response is forthcoming, a 
participant in an instant messaging conversation may erroneously 
assume either that the communication partner has left or that it is 
her turn to type again, leading to two messages "crossing on the 
wire". 


To avoid this uncertainty, a number of commercial instant messaging 
systems feature an "is-typing" indication sent as soon as one party 
starts typing a message. In this document, we describe a generalized 
version of this indication, called the isComposing status message. 

As described in Section 3 in more detail, a status message is 
delivered to the instant message recipient in the same manner as are 
the messages themselves. The isComposing status messages can 
announce the composition of any media type, not just text. For 
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example, it might be used if somebody is recording an audio or video 
clip. In addition, it can be extended to convey other instant 
messaging user states in the future. Below, we will call these 
messages "status messages" for brevity. 


The status messages are carried as XML, as instances of the XML 
schema defined in Section 6, and labeled as an 
application/im-iscomposing+xml content type. 


These status messages can be considered somewhat analogous to the 
comfort noise packets that are transmitted in silence-suppressed 
interactive voice conversations. 


Events and extensions to presence, such as PIDF [6], were also 
considered but have a number of disadvantages. They add more 
overhead, as an explicit and periodic subscription is required. 
For page-mode delivery, subscribing to the right user agent and 
set of messages may not be easy. An in-band, message-based 
mechanism is also easier to translate across heterogeneous instant 
messaging systems. 


The mechanism described here aims to satisfy the requirements in [7]. 
Terminology and Conventions 


This memo makes use of the vocabulary defined in the IMPP Model 
document [1]. In this memo, terms such as CLOSED, INSTANT MESSAGE, 
OPEN, PRESENCE SERVICE, PRESENTITY, WATCHER, and WATCHER USER AGENT 
are used with the same meaning defined therein. The key words MUST, 
MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and 
OPTIONAL in this document are to be interpreted as described in BCP 
14; REC 2119: [21]; 


This document discusses two kinds of messages; namely, the instant 
message (IM) conveying actual content between two or more users 
engaged in an instant messaging conversation, and the status message, 
described in this document, which indicates the current composing 
status to the other participants in a conversation. We use the terms 
"content message" and "status message" for these two message types. 


Description 
1. Overview 
We model the user of an instant messaging system as being in one of 
several states, in this document limited to "idle" and "active". By 


default, the user is in "idle" state, both before starting to compose 
a message and after sending it. 
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3.2. Message Composer Behavior 


Only the instant messaging user agent actively composing a content 
message generates status messages indicating the current state. When 
the user starts composing a content message (the actual instant 
message), the state becomes "active", and an isComposing status 
message containing a <state> element indicating "active" is sent to 
the recipient of the content message being composed. As long as the 
user continues to produce instant message content, the user remains 
in state "active". 


There are two sender timers: the active-state refresh interval, and 
the idle time-out interval. 


The active-state refresh interval determines how often "active" state 
messages are sent while the composer remains in "active" state. The 
interval is chosen by the composing user and indicated in the 
<refresh> element in the status message, expressed in integer 
seconds. Each transmission of the isComposing message resets the 
timer. The interval SHOULD be no shorter than 60 seconds. A message 
composer MAY decide not to send active-state refresh messages at all. 
This is indicated by omitting the refresh interval; this will cause 
the receiver to assume that it has gone idle after 120 seconds. (In 
most cases, the content message will have been sent by then.) No 
refresh messages are sent in "idle" state. 


The active-state refresh mechanism deals with the case in which 
the user logs off or the application crashes before the content 
message is completed. 


If the user stops composing for more than a configured time interval, 
the idle timeout, the state transitions to "idle", and an "idle" 
status message is sent. If the user starts composing again while in 
"idle" state, the state transitions to "active", and the 
corresponding status message is sent. Unless otherwise configured by 
the user, the idle timeout SHOULD have a default value of 15 seconds. 


If a content message is sent before the idle threshold expires, no 
"idle" state indication is needed. Thus, in most cases, only one 
status message is generated for each content message. In any event, 
the message rate is limited to one status message per refresh 
threshold interval. 
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The state transitions are shown in Figure 1. 


+------------- + 
| +----------- +| 
|| || 
$------ > | idle | <-------- + 
| || || | 
| [+----------- + | 
+------ +--—---- + 
content | | idle timeout 
msg. sent | | composing | w/o activity 
---1------- | | ------------- | ------------------ 
<= | | "active" msg. | "idle" status msg. 
| | | 
| +-----—- V------ + | 
| | | | 
+------ + active arg ee + 
| | 
| |------+ 
t-----— aaa + refresh timeout 
| ee Be ee Se 
| | "active" status msg 
+--—----------- + 


Figure 1. Sender State Diagram 
3.3. Status Message Receiver Behavior 


The status message receiver uses the status messages to determine the 


state of the content message sender. If the most recent "active" 
status message contained a <refresh> value, the refresh time-out is 
set to that value; otherwise, it is 120 seconds. The state at the 


receiver transitions from "active" to "idle" under three conditions: 
1. A status message with status "idle" is received. 
2. A content message is received. 


3. The refresh interval expires. 


Receivers MUST be able to handle multiple consecutive isComposing 
messages with "active" state, regardless of the refresh interval. 
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The state transitions are shown in Figure 2. 


+------------- + 
| +----------- +| 
|| | | 
+------ >| idle |<------ + 
|| || 
| +----------- +| 
+------ +------ + 


"idle" recd. 


| 
"active" msg.| refresh timeout 
| 
| 
| 
| 


or content recd. or 120s 
+------ V------ + 
| | 
+------ + active $HSSs5= + 
| | 
| | 
4+------------- + 


Figure 2. Receiver State Diagram 
3.4. Message Content 


We briefly describe the message content to summarize the discussion 
above. This description is non-normative. The schema (Section 6) 
should be consulted for the normative message format. 


The message consists of an <isComposing> element, with a mandatory 
<state> element indicating the composer state; i.e., idle or active. 
In addition, there are three optional elements: <lastactive>, 
indicating the time of last activity; <contenttype>, the type of 
message being created; and <refresh>, the time interval after which 
the receiver can expect an update from the composer. Details are 
given in the following section. 


3.5. Additional Status Information 
The status message contains additional optional elements to provide 


further details on the composition activity. Any of these can appear 
in both "active" and "idle" state messages. 
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The optional <lastactive> element describes the absolute time when 
the user last added or edited content. 


The optional <contenttype> element indicates the type of medium in 
which the messaging terminal is currently composing. It can contain 
either just a MIME media type, such as "audio" or "text", or a media 
type and subtype, such as "text/html". It is best understood as a 
hint to the user, not a guarantee, that the actual content message 
will indeed contain only the content indicated. It allows the human 
recipient to be prepared for the likely message format. 


To further describe message composition, the XML schema or the set of 
allowable state names can be extended in future documents. 

Recipients of status messages implementing this specification without 
extensions MUST treat state tokens other than "idle" and "active" as 
"idle". Additional elements MUST use their own namespaces and MUST 
be designed so that receivers can safely ignore such extensions. 
Adding elements to the namespace defined in this document is not 
permitted. 


The isComposing status message MAY be carried in CPIM messages [3]. 


Such a wrapper is particularly useful if messages are relayed by a 
conference server since the CPIM message maintains the identity of 
the original composer. 


4. Using the Status Message 


The isComposing status message can be used with either page mode or 
session mode, although session mode is a more natural fit. In 
session mode, the status message is sent as part of the messaging 
stream. Its usage is negotiated just like any other media type in 
that stream, with details depending on the session mode protocol. 


Sending the status messages within the session-mode messaging stream 
has at least three benefits. First, it ensures proper ordering and 
synchronization with the actual content messages being composed. In 
messaging systems that guarantee in-order delivery of messages, this 
approach avoids having an active indication appear at the receiver 
after the actual message has been delivered, due to message 
reordering across two delivery mechanisms. 


Secondly, end-to-end security can be applied to the messages. 
Thirdly, session negotiation mechanisms can be used to turn it on and 
off at any time, and even to negotiate its use in a single direction 
at a time. 
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Usage with page mode is also straightforward: The status message is 
carried as the body of a page mode message. In SIP-based IM, The 
composer MUST cease transmitting status messages if the receiver 
returned a 415 status code (Unsupported Media Type) in response to a 
MESSAGE request containing the status indication. 


The sender cannot be assured that the status message is delivered 
before the actual content being composed arrives. However, SIP page 
mode is limited to one unacknowledged message, so out-of-order 
delivery is unlikely, albeit still possible if proxies are involved. 


5. Examples 


<?xml version="1.0" encoding="UTF-8"?> 
<isComposing xmlns="urn:ietf:params:xml:ns:im-iscomposing" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="urn:ietf:params:xml:ns:im-composing 
iscomposing.xsd"> 
<state>active</state> 
<contenttype>text/plain</contenttype> 
<refresh>90</refresh> 
</isComposing> 


<?xml version="1.0" encoding="UTF-8"?> 
<isComposing xmlns="urn:ietf:params:xml:ns:im-iscomposing" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="urn:ietf:params:xml:ns:im-composing 
iscomposing.xsd"> 
<state>idle</state> 
<lastactive>2003-01-27T10:43:002Z</lastactive> 
<contenttype>audio</contenttype> 
</isComposing> 


6. XML Document Format 


An isComposing document is an XML document that MUST be well formed 
and SHOULD be valid. isComposing documents MUST be based on XML 1.0 
and MUST be encoded by using UTF-8. This specification makes use of 
XML namespaces for identifying isComposing documents. The namespace 
URI for elements defined for this purpose is a URN using the 
namespace identifier ’ietf’. This URN is: 


urn:ietf:params:xml:ns:im-—iscomposing 
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6.1. XML Schema 


<?xml version="1.0" encoding="UTF-8"?> 
<xs:schema targetNamespace="urn:ietf:params:xml:ns:im-iscomposing" 
elementFormDefault="qualified" 
attributeFormDefault="unqualified" 
xmlns:xs="http://www.w3.org/2001/XMLSchema" 
xmlns:tns="urn:ietf:params:xml:ns:im-iscomposing"> 
<xs:element name="isComposing"> 
<xs:complexType> 
<xs:sequence> 
<xs:element name="state" type="xs:string"/> 
<xs:element name="lastactive" type="xs:dateTime" 
minOccurs="0"/> 
<xs:element name="contenttype" type="xs:string" 
minOccurs="0"/> 
<xs:element name="refresh" type="xs:positivelInteger" 
minOccurs="0"/> 
<xs:any namespace="##other" processContents="lax" 
minOccurs="0" maxOccurs="unbounded"/> 
</xs:sequence> 
</xs:complexType> 
</xs:element> 
</xs:schema> 


7. Security Considerations 


The isComposing indication provides a fine-grained view of the 
activity of the entity composing and thus deserves particularly 
careful confidentiality protection so that only the intended 
recipient of the message will receive the isComposing indication. 


Since the status messages are carried by using the IM protocol 
itself, all security considerations of the underlying IM protocol 
also apply to the isComposing status messages. 


There are potential privacy issues in sending isComposing status 
messages before an actual conversation has been established between 
the communicating users. A status message may be sent even if the 
user later abandons the message. It is RECOMMENDED that isComposing 
indications in page mode are only sent when a message is being 
composed as a reply to an earlier message. This document does not 
prescribe how an implementation detects whether a message is in 
response to an earlier one in page mode, but elapsed time or user 
interface behavior might be used as hints. 
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8. IANA Considerations 
8.1. Content-Type Registration for ‘’application/im-iscomposing+xml’ 


To: ietf-types@iana.org 

Subject: Registration of MIME media type application/ 
im-iscomposing+xml 

MIME media type name: application 

MIME subtype name: im-iscomposingt+xml 

Required parameters: (none) 

Optional parameters: charset; Indicates the character encoding of 
enclosed XML. Default is UTF-8. 

Encoding considerations: Uses XML, which can employ 8-bit characters, 
depending on the character encoding used. See RFC 3023 [4], 
section 3.2. 

Security considerations: This content type is designed to carry 
information about current user activity, which may be considered 
private information. Appropriate precautions should be adopted to 
limit disclosure of this information. 

Interoperability considerations: This content type provides a common 
format for exchange of composition activity information. 

Published specification: RFC 3994 

Applications which use this media type: Instant messaging systems. 

Additional information: none 

Person & email address to contact for further information: Henning 
Schulzrinne, hgs@cs.columbia.edu 

Intended usage: LIMITED USE 

Author/Change controller: This specification is a work item of the 
IETF SIMPLE working group, with the mailing list address 
simple@ietf.org. 

Other information: This media type is a specialization of 
application/xml RFC 3023 [4], and many of the considerations 
described there also apply to application/im-iscomposing+txml. 
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8.2. URN Sub-Namespace Registration for 
‘urn:ietf:params:xml:ns:im-iscomposing’ 


URI: urn:ietf:params:xml:ns:im-iscomposing 

Description: This is the XML namespace for XML elements defined by 
RFC 3994 to describe composition activity by an instant messaging 
client using the application/im-iscomposing+xml content type. 

Registrant Contact: IETF, SIMPLE working group, simple@ietf.org, 
Henning Schulzrinne, hgs@cs.columbia.edu 

XML: 


BEGIN 
<?xml version="1.0"?> 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" 
"http://www.w3.org/TR/xhtml-basic/xhtml-basicl10.dtd"> 
<html xmlns="http://www.w3.org/1999/xhtm1"> 
<head> 
<meta http-equiv="content-type" 
content="text/html; charset=iso-8859-1"/> 
<title>Is-composing Indication for Instant Messaging</title> 
</head> 
<body> 
<hl>Namespace for SIMPLE iscomposing extension</h1> 
<h2>urn:ietf:params:xml:ns:im-composing</h2> 
<p>See <a href="(URL of published RFC]">RFC3994</a>.</p> 
</body> 
</html> 
END 


8.3. Schema Registration 
This section registers a new XML schema per the procedures in [5]. 
URI: urn:ietf:params:xml:schema:im-composing 


Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 
Henning Schulzrinne (hgs@cs.columbia.edu). 


The XML for this schema can be found as the sole content of Section 
6.1. 
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